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Related Applications 
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Field of the Invention 

This invention relates to an integrated medical database system. More 
specifically, this invention relates to a medical database for the emergency medical 
transportation industry. 

Description of the Related Technology 

Current documentation procedures in the air medical transport industry are based 
on an inefficient paper and pencil technology. Important information is frequently 
collected on loose sheets of paper. In the environment of emergency medical transport, 
little time is available to neatly chart and document all pertinent and required 
information on a single document. Dispatch data, demographic data and clinical data 
are normally tracked as fragmented pieces of information which are later coalesced into 
a complete patient chart. In many cases, these data include the same information, thus 
forcing the input of redundant information. The resultant chart is therefore vulnerable 
to being incomplete and unreliable. In a medical setting, incomplete information can 
lead to disastrous clinical results. 

This same technology is used to support industry quality improvement and 
billing procedures and submit letters of transport justification. This paperwork is 
usually carried out at a later date, prolonging account receivable times in many instances 
to the point of compromising and jeopardizing service compensation. Inventory 
stocking and tracking is similarly a victim of extended turnover times and is often 
incomplete and inaccurate. 



Background of the Invention 
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The fragmentation throughout the medical transport environment is also evident 
in the myriad of entities throughout the country practicing different standards of care 
and documentation. As is the case in other segments of the healthcare industry, even 
seemingly simple tasks of communicating among the various entities, as well as among 
5 sections of a single providing entity, is severely hampered by the lack of a common 
communication format. This is especially evident when certain aspects of the system 
(such as computerized clinical laboratory result displays) have been upgraded with a 
uniquely tailored computerized system, while the remaining functions are still 
performed in an archaic manner. While the upgraded system may be effective for one 

1 0 singular aspect, such as dispatching, lab reporting, or chart dictating, the remainder of 

the system does not improve its effectiveness due to the other archaic components. 

Although others have attempted to remedy this conflict, no fully integrated 
medical systems have been developed. For example, the Air Medical Software 
(Innovative Engineering of Lebanon, New Hampshire) provides computer software for 

15 dispatching emergency crews to accident scenes and managing flight information. 

However, it does not provide comprehensive integration of the flight information with a 
clinical diagnosis, billing system and administration system. 

Air medical transport services suffer from a lack of understanding as to their 
effectiveness by governmental, academic and commercial organizations. A system is 

20 needed to collect solid statistics on how these systems can save lives and justify their 

existence and growth. Furthermore, medical crew evaluations and areas for 
improvement can be compared to known benchmarks after statistics on past service 
become widely available. 

Therefore, what is needed is a comprehensive system that includes modules for 

25 dispatching emergency medical teams, tracking their movement to and from the 
accident scene, managing a clinical diagnosis and treatment and accurately billing the 
patient for the services rendered. 



Summary of the Invention 
30 One embodiment of the present invention is a computerized integrated data 

management system for tracking a patient incident. The data management system 
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includes: a first module capable of dispatching an emergency transport crew specific to 
a patient incident requiring emergency medical care by the emergency transport crew; 
and a second module capable of receiving information from the first module and billing 
a patient appropriately for costs indicative of the patient incident. 
5 Another embodiment of the invention is a computerized integrated data 

management system for tracking a patient incident that includes: a first module capable 
of interpreting data relating to the medical condition of a patient involved in a patient 
incident requiring emergency medical care by an emergency medical transport crew and 
determining a diagnosis for the patient; and a second module capable of receiving 
1 0 information from the first module and billing the patient appropriately for the patient 
incident. 

Yet another embodiment of the invention is a computerized method of 
generating a patient encounter record. The method includes the steps of: collecting 
flight information relating to an emergency transport crew dispatch; collecting patient 

1 5 information from a clinical encounter associated with a patient incident requiring 

emergency medical care by the emergency transport crew; and integrating the patient 
information with the flight information to produce an encounter record indicative of the 
patient's clinical encounter. 

Still another embodiment of the invention is a method of diagnosing an illness in 

20 a patient. This method includes the computer implemented steps of: collecting 
information from a physical exam at the site of a patient's incident requiring emergency 
medical care by an emergency medical transport crew; determining a list of possible 
diagnoses based on the physical exam; and recording the diagnosis results in a 
centralized database of patient emergency medical information. 

25 

Brief Description of the Drawings 
Figure 1 is a diagram illustrating the on-line computing environment of the 
medical database system, including a dispatch interface computer, server computer, 
backup computer, clinical and diagnosis interface computer, administrative interface 
30 computer and billing interface computer. 
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Figure 2 is a flow diagram illustrating the overall process performed by the 
medical database system. 

Figure 3 is a block diagram illustrating the flow of data among the dispatch 
module, the clinical module, and the billing module, in one embodiment of the medical 
5 database system. 

Figure 4 is a flow diagram illustrating the Initialize Dispatch Module process of 
Figure 2. 

Figure 5 is a flow diagram illustrating the Initialize Clinical Module process of 
Figure 2. 

1 0 Figure 6 is a flow diagram illustrating the Run Physical Exam process of Figure 

5. 

Figure 7 is a flow diagram illustrating the Determine Diagnosis and Rank 
process of Figure 5. 

Figure 8 is a flow diagram illustrating the Initialize Administration Module 
1 5 process of Figure 2. 

Figure 9 is a flow diagram illustrating the Advanced Procedure Treatment 
process of Figure 5. 

Figure 10 is a flow diagram illustrating the Initialize Billing Module process of 
Figure 2. 

20 

Detailed Description of the Preferred Embodiment 
The following detailed description presents a description of certain specific 
embodiments of the present invention. In this description, reference is made to the 
drawings wherein like parts are designated with like numerals throughout. 
25 For convenience, the discussion of the invention is organized into the following 

principal sections: Introduction, Hardware Overview, Software Initialization, Data Flow 
Between Modules and Description of Software Modules. 



30 
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INTRODUCTION 

The present invention relates to an object oriented, interactive, international, 
client-server service for the medical transport industry. The service integrates all 
aspects of patient record documentation into a single complete electronic chart. A 
5 server computer provides chart database information access to multiple transport 
providers simultaneously by securely transmitting, storing and maintaining standardized 
patient data, for instance, using guidelines set forth by the Scrambling Standards 
Organization. Individual transport-providing entities, such as helicopter and ambulance 
companies, obtain coded access to this server via phone lines with a modem equipped 

10 personal computer. Security is maintained by assigning each entity a unique code or 
identifier. Integrated Services Digital Network (ISDN) lines, Digital Satellite Systems 
(DSS) or digital wireless systems may also be used for communication. 

Each crew member involved in the patient's chart documentation, i.e. dispatcher, 
flight nurse, paramedic and physician, as well as administrator and collector, possess 

15 coded access to chart portions relevant to their responsibilities and level of care 
provided. The chart is then electronically generated from the compendium of the 
information entered in a standardized fashion and in accordance with minimum industry 
documentation requirements and the inventory of financial health care standards. The 
system provides complete and accurate chart documentation and maintains internal 

20 consistency between each separate module. Furthermore, any sentinel events are 
automatically referred to the appropriate, responsible party. A sentinel event is any 
action during the encounter that might require a further review. Examples of sentinel 
events are scene times exceeding 40 minutes, nonsensical data entry by an emergency 
transport crew member, supply shortages for equipment not utilized or repeated claim 

25 denials. 

Billing can be submitted electronically to the appropriate party in an appropriate 
format which reduces the accounts receivable times for each patient encounter. Letters 
of justification are automatically generated as well as follow up letters and utilization 
review reports. Inventory reports and lists of necessary base supplies and medicines are 
30 also electronically updated to appropriate supply centers and administrators. 

Customized and research reports can also be provided rapidly. 
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Data security and an automatic backup are provided. Although the chart data is 
normally made the property of the respective transport service provider, the system can 
retain non-proprietary data to provide industry benchmarking, quality assurance analysis 
and clinical research opportunities. Such standardized data collection and 
5 documentation will furthermore enable the development of an Emergency Medical 
Services data library to assist in the justification and legislation of governmental 
preventive policies for public safety. 



HARDWARE OVERVIEW 

10 Figure 1 provides an overview of the computer hardware involved in one 

embodiment of the medical database system. In this embodiment, the medical database 
system 10 includes a server computer 12. The server computer 12 can be based on any 
well-known microprocessor such as those manufactured by Intel, Motorola, IBM or 
DEC. The server computer should be able to enable rapid simultaneous access to many 

1 5 users of the system. In one preferred embodiment, the server computer 1 0 is an Intel 
Pentium class computer having at least 32 Megabytes of RAM and a four gigabyte hard 
disk drive and a 100MHz processing speed. Of course, many other standard or non- 
standard computers may support an implementation of the present invention. 

The database application may be programmed in, for instance, ACIUS's 4th 

20 Dimension language and used in conjunction with the 4D Server and Client program. 

Also, another alternative computer environment is Microsoft Corporation's Visual Basic 
language with the BackOffice 2.5 Client Server program. It can therefore run in a 
standard Windows/Macintosh point-and-click office environment, and requires no 
additional, specialized software programming from the user. Of course, other standard 

25 or non-standard computer environments may support an implementation of the present 

invention. 

As illustrated, the server computer can access a statistical database 14 to store 
and extract statistical information from data entered during patient encounters. The 
collected statistics might include, for example, average scene and transport times, 
30 number of transport requests per demographic region and time of year, average number 

of advanced procedures performed by crew members and number of complications 
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encountered. In addition, the database 14 can hold information relating to the average 
length of time to process claims by category and payment plan. 

The server computer can also be linked to a regional trauma database 15. The 
database 15 holds information relating to local trauma centers, emergency medical 
5 practice and other local trauma-related information. 

The dispatch module on the server computer 12 can be accessed via an interface 
to a dispatch computer 20, which might reside, for example, at the dispatch center that 
receives the initial call to deploy an emergency medical team. The dispatch computer 
20 can provide just a communications interface to the server computer 12 so that it acts 

1 0 as computer terminal, or it can contain a portion of the dispatch module. 

Based on the scene location and needs of the patient, the dispatch center might 
deploy a helicopter 24, airplane 25 or ambulance 26. The dispatch computer 20, as 
explained in more detail below, communicates with software for collecting information 
on the patient encounter and scheduling and deploying a crew to assist the injured 

15 patient. Within the medical database system 10, the helicopter 24, airplane 25 or 

ambulance 26 would include a portable computer 30 that is used by the emergency 
medical team during the patient encounter. A wireless connection 32 can be made by 
the portable computer 30 to the server computer 12 to update the database 14 after any 
data has been entered. The portable computer 30 can include clinical and diagnosis 

20 modules to assist the emergency medical team in treating the injured patient, or can act 
as a terminal to communicate with these modules on the server computer 12. As will be 
explained below, the clinical and diagnosis modules can help the emergency medical 
team determine the proper diagnosis and treatment of the patient. 

The medical database system 10 also includes a billing computer 36 in 

25 communication with the server computer 12. The billing computer 36 interfaces with 

the server computer 12 to run the billing module for tracking inventory. The software 
billing module can be stored directly on the billing computer 36 or, alternatively, stored 
on the server 12 and accessed via the billing computer 36. The billing module is used to 
track inventory and medical equipment. In addition, it is used during the patient 

30 encounter for providing billing functions within the medical database system 10. The 
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billing computer 36 communicates with a laser printer 38 to provide printed reports and 
bills to hospitals, patients and medical centers. 

An administration computer 40 interfaces with the server computer 12 to 
provide run administrative reports. These reports might relate to the statistical 
information contained in the statistical database 14. In addition, the administration 
computer 40 might run reports that relate to payroll, inventory, flight training or many 
other administrative issues. 

It should be noted that the dispatch interface computer 20, portable computer 30 and 
billing computer 36 can communicate with the server computer 12 through a variety of 
mechanisms. For example, a wireless LAN or cellular network may connect each 
computer with one another. In another embodiment, dedicated or dial-up phone lines 
can be used to communicate between the different computers. 

SOFTWARE INITIALIZATION 

Referring now to Figure 2, an overall process 50 of initializing the various 
software modules within the medical database system 10 is shown. Although Figure 2 
illustrates the initialization of all software modules in the system, it should be realized 
that each module can be initialized within a separate computer. For example, the 
dispatch module can be initialized within the dispatch computer 20 while the billing 
module is initialized within the billing system 36. 

The process 50 begins at a start state 52 and then moves to state 54 wherein a 
user password is requested. If the user password is accepted at a decision state 55, the 
process 50 moves to a decision state 56 to determine whether this is a repeated access to 
the system. However, if the password is not accepted at the decision state 55, the 
process 50 returns to state 54 to re-request the user password. 

If a determination is made at the decision state 56 that this is a repeated access, 
the process 50 moves to a state 57 to log the time of the access and then to a state 58 to 
log the identity of the user making the access. A log of the access changes to the system 
are then logged at a state 59. The process 50 then moves to a decision state 60 wherein a 
determination is made whether a dispatcher has initiated this call. However, if a 



determination is made at the decision state 56 that this was not a repeated access, the 
process 50 moves directly to the decision state 60. 

If a determination is made at the decision state 60 that a dispatcher initiated this 
call, the process 50 moves to state 61 wherein a scheduling submodule is initialized. 
5 The scheduling submodule, as discussed above, tracks base information, crew 
schedules, helicopter flight times and the like. The process then moves to state 62 
wherein the scheduling and base information from the dispatcher is shared and extracted 
into the clinical and diagnosis modules, and thereafter sent to the clinical and diagnosis 
computer interface 30 (Figure 1). The process 50 then moves to a process state 65 

10 wherein the dispatch module is initialized. However, if a determination was made at the 
decision state 60 that a dispatcher did not originate the call, the process 50 moves to 
state 63 and initializes the scheduling submodule. The process 50 then moves to 
process state 65 and initializes a dispatch module. 

The dispatch module is divided into four interrelated submodules: Schedule, 

1 5 Standby, Flight and Transfer (not shown). The Scheduling submodule accomplishes the 

task of preparing schedules for the respective transport bases of an air medical service. 
The scheduling submodule is responsible for tracking dispatch, flight crew members, 
base physician, pilot (co-pilot), and stationed helicopters in service for a given shift. 
Data can be entered well in advance and updated up to the time a flight is actually 

20 dispatched. The process 65 of initializing and running a dispatch module is explained in 

more detail with reference to Figure 4. 

The Scheduling submodule shares shift information already entered in the 
Scheduling module to generate a flight record based on the date, time, and base from 
which the flight takes place. As mentioned above, upon flight dispatch, the dispatcher 

25 will receive the name of the current base physician, crew and helicopter information for 

verification. 

The Standby submodule enables the dispatcher to collect information regarding 
the accident scene location, ground contacts, basic patient scenario and demographics 
prior to committing and dispatching a flight. This submodule allows agencies 
30 requesting air medical transport services to provide an early warning, verify the need for 

air transport and hence shorten the response and flight time to the accident scene. 
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The Transfer submodule coordinates patient transfers from one location to 
another. For example, a critical patient may need to be transported from a local hospital 
to a specialty hospital in order to receive a unique operation. The Transfer module 
manages the information associated with the patient transfer, such as origin, destination, 
5 purpose and the like. 

The Flight submodule constitutes the main portion of the Dispatch module, and 
records information pertinent to the flight proper. Flights are tracked through timed and 
recorded position checks in accordance with Federal Aviation Agency (FAA) and 
Commission on Accreditation of Medical Transport requirements. Accident scenes are 
1 0 recorded with rendezvous and landing zone locations, address and zip codes as well as 
standard map coordinates, such as Thomas Brothers Reference points. In addition, 
waypoint/longitude-latitude location, the requesting agency, any ground contacts, and an 
appropriate communication frequency and the reason for call are all recorded by the 
J3 flight submodule. 

yi 1 5 Further, the type and nature of call, base hospital, and name of the closest and 

J; receiving hospitals are collected. Mileage traveled and time stamping, including scene 

6i time, flight time and specialty times, such as crew change and pick up times as well as 

f 1 «T 

s on site times, are calculated and recorded automatically from the information provided 

'% and dispatch feedback from flight crew. In addition, the reason and time for flight 

^ 20 diversions and re-routings and elected ground transports with justification and alternate 

p plans are entered into the system as well. Multiple flights can be orchestrated and 

" f recorded in parallel, while dispatcher and/or base physician change shifts during a flight 

- all data is constantly updated. When backup vehicles are required and dispatched, the 
flight information is transferred automatically from the primary responding crew to the 
25 backup crew. 

Flight information is saved after verification as a dispatch record with a monthly 
flight number. A monthly American Air Medical Service (AAMS) record can then be 
automatically generated. Flight information can be canceled at any time, as well as 
deleted completely from the database with the appropriate option. 
30 Once the dispatch module has been initialized at the process 65, a clinical 

module is initialized at a process 70. The Clinical module is also divided into several 
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submodules: patient demographics, basic incident description, treatment rendered prior 
to air medical service arrival, general assessment including vital signs, intake and output 
as well as trauma scores, physical exam by systems, impression and diagnosis, treatment 
including medications and advanced procedures, en route events, quality assurance, 
5 justification of transport, and patient disposition. A specialized neonatal submodule can 
also be accessed if necessary. 

Although any submodule can be accessed to begin a chart, the submodules are 
normally ordered in the traditional clinical format. Patient demographic information is 
first taken automatically from the dispatch data, if available. The patient information is 
10 first completed; including flight reference, date, base, scene, reason for transport, scene, 
landing and scene times, patient name, age, sex, weight and race, allergies, current 
medications, past medical history, place of exam, language barrier existence, type of 
l*% call, nature of call, response such as night flight, in/out county intensive care unit to 

i!f intensive care unit (icu-icu), transport team only, out county emergency department to 

Ul 1 5 emergency department (ed-ed) or emergency transport service with no charge. 
fj% Incident information, including the occurrence time, incident type (for example, 

^ motor vehicle accident, gun shot, fall, stabbing, drowning, loss of consciousness, 

s pedestrian, cerebrovascular accident, chest pain, arrest, burn), type and description of 

yp s accident (damage, extrication, loss of consciousness, other) can then be entered. Next, 

^* 20 any treatment that was provided prior to air medical crew arrival is entered into the 

□ system. The name of first responders, along with the level of care provided and type of 

immobilization, airway management, intravenous access, cardiopulmonary 
resuscitation, medications and other treatments are recorded. The patient's Glasgow, 
CRAMS and Champion trauma scores are recorded separately, and in such a manner 
25 that consistency amongst them is assured. 

The patient's vital signs, including systolic/diastolic blood pressure, pulse rate, 
respiratory rate, pulse oximetry, fluid intake/output along with the time of measurement 
are recorded. In addition, the arrival time of the aircraft on the scene, departure and 
hospital arrival times are once again displayed. Other important data pertinent to vital 
30 signs can be recorded in this module. 



-11- 



The physical examination portion is also divided into sections related to 
particular physiological components. A default standard normal examination for each 
system is provided, wherein all or portions thereof can be selected. Results can be 
typed, or selected from standard examination result options. The first examination is a 
5 neurological examination with input options such as alert, oriented times three, full 

recall, pupils equal and round and reactive to light and moving all extremities. The next 
examination is a skin exam with options such as good color, warm and dry, capillary 
refill less than 2 seconds, pulses well palpable. A head, eyes, ears, nose and throat exam 
can be performed, followed by a neck and chest examination. A cardiac examination 

1 0 having options such as regular rate and rhythm, no murmur rubs or gallop, and normal 
sinus rhythm on the monitor can be performed. The next examination can be 
abdominal, followed by pelvic and extremities examinations. 

Once the results of these standard body examinations are received by the system, 
the physicians diagnoses are entered. In addition, the system generates pre-set 

1 5 diagnoses based on the results it has received during the clinical examination. Many of 

the results can be automatically recorded by having the monitoring equipment hooked 
directly into the portable computer system. Industry standard ICD-9 billing codes for 
each diagnosis can then be automatically determined and recorded by the system. These 
codes are used by the billing module to generate statements to the patient. 

20 A treatment plan is next entered into the system by the emergency team. The 

treatment that occurred prior to the arrival of the air medical crew is automatically 
completed from the aforementioned section, if provided. Equipment used 
(Electrocardiogram, vital sign monitor, pulse oximeter, suction devices, ventilator, etc.), 
respiratory management, as well as intravenous access by crew, and neurological 

25 immobilization techniques (cervical collar, long/short back board, ked sled, etc.) and 

miscellaneous techniques (temperature measurements, bulb syringe, suction catheter, 
etc.) are recorded. All medications other than those applied under the standard 
advanced cardiac life support protocols are recorded from an extensive list within the 
system. Advanced procedures with procedure-specific documentation are recorded 

30 accurately. These include intubation, chest tube placement, pericardiocentesis, invasive 
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line placement, advance cardiac life support, special medication administration, 

Mannitol infusion or Solumedrol administration. 

Special documentation for the advanced procedure of intubation/cricothyrotomy 

includes the use (or mouse) of rapid sequence intubation techniques, route of successful 
5 intubation along with tube size, best visualization procedure, depth at which tube is 

secured, and confirmation technique of tube placement. Identification of successful and 

unsuccessful intubation medical crews can also tracked as a way to identify possible 

crew training issues. Pulse oximetry recordings can be performed before or after the 

procedure. Extensive choices are available to comment on the procedure and note any 
10 complications that were encountered by the medical team. The medications used during 

this procedure are recorded in a special medications submodule. 

The special medications submodule records, in addition to rapid sequence 

intubation (RSI) medications, the name and dose of the medication given along with the 

identification of the administering crew member in accordance with Joint Commission 
15 on Accreditation of Health Care Organization Requirements (JCAHO). 

Any comments associated with the drug administration and ensuing complications can 

be recorded in this submodule. 

Special documentation for any chest tube placement procedure is included in the 

system to record the patient's indication, type of technique (tube versus needle), 
20 identification of successful and unsuccessful performers, location of placement, size of 

tube and time of placement. In addition, the aspirate type and amount are recorded. 

Again, pulse oximetry measurements pre and post procedure are recorded into the 

system. Comments and complications ensuing from the procedure are as above 

recorded. 

25 For pericardiocentesis, the procedure, time, identification of successful and 

unsuccessful performers, catheter and syringe sizes, aspirate amount and type, patient 
improvement as well as comments and complications (vascular damage, air embolus, 
etc.) are all included in the data acquisition by the system. 

Invasive line procedure documentation includes identification of successful and 

30 unsuccessful performing crew, site of placement, type of access line, time of placement 
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and comments and complications encountered. This can be used later for medical crew 

evaluations and training. 

The advanced cardiac life support documentation includes the beginning and end 

of resuscitation times, medications in the order and dose administered, electricity 
5 administered (defibrillation, cardioversion), as well as other comments relating to the 

events that occurred. Vital signs and times are recorded or directly downloaded from 

the recording monitor. 

The administration of particular drugs such as Mannitol are tightly controlled by 

law and require special documentation. The medical database system can complete this 
10 documentation by collecting the identification of the administering crew member, the 

patient's Glasgow Coma Score pre and post administration, dose given, indications and 

comments and complications encountered. 

Similarly, Solumedrol administration also requires extra documentation, 

including identification of crew administering the medication, estimated level of 
15 neurological injury, dose and time given, as well as comments and complications 

encounters (allergic reaction, hypotension, etc.). 

Other data is collected en route from the incident scene to the destination. The 

data collected can include the changed/ unchanged patient status, name of person to 

whom report is given, name of accepting physician, and follow up status of transported 
20 patient. The process 70 of initializing and running a clinical module is explained in 

more detail with reference to Figure 5. 

The process 50 then moves to a process 75 and initializes an administration 

module for collecting and processing the information from the clinical encounter. The 

hierarchical structure of the system enables it to perform administrative services along 
25 with quality assurance as well. Indeed, from the chart's data, standard administrative 

reports can be automatically generated and sent to the appropriate personnel. 

Furthermore, a letter of justification for transport and interventions rendered is 

automatically generated in the required format from the chart components. With this 

same service, thank you letters and letters of follow up are directed as well to the 
30 responsible parties involved. The Emergency Medical Service can be provided with key 

preventive information on environmental health and public safety hazards encountered 
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on scene by the transport crew. Also, internal reports and memos can be disseminated 
across the network of computers. And sentinel events such as those associated with 
neglect of care or failure to provide adequate care and safety, will immediately and 
automatically be called to the attention of the appropriate administrator to provoke 
5 corrective action. The administration module process 75 is explained in more detail 

with reference to Figure 8. 

Once the administration process has begun and the patient information is 
collected by the system 10, the process 50 moves to a process state 80 and initializes the 
billing module of the medical database system. The billing component takes advantage 
10 of the extensive patient information collected in the aforementioned modules. The 
demographic documentation is automatically incorporated from the dispatch and clinical 
modules. Precise billing for procedural interventions and inventory used in the 
=j treatment of a patient is exactly accounted for as was noted and recorded in the clinical 

y component. In addition, procedures requiring the use of extensive inventory, such as 

II 15 intubations, chest tube placements, etc., are automatically evaluated for use of the 
S required specific paraphernalia for completeness on the bill. When medications are 

i; administered, the billing component automatically selects the number of inventory unit 

amounts to be charged for from the total dose administered. The bill can then be 
□ processed electronically in the required format to the correct agency. 

!* 20 The same data used for billing is also used to update stock inventory on the 

3 respective transport vehicle and base after each encounter, to ensure adequate equipment 

supplies. Coupled to the supplier's inventory list, this information can automatically 
signal the need for delivery of equipment to the required base. Once the billing module 
is initialized at process 80, the overall process 50 terminates at an end state 85. 

25 

DATA FLOW BETWEEN MODULES 
Referring now to Figure 3, a block diagram of the data flow between the various 
modules within the medical database system is illustrated. Figure 3 illustrates the flow 
of data between a dispatch module 100, clinical module 105 and billing module 110. 
30 The dispatch module 100 includes a scheduling submodule 112, a standby submodule 

1 14, a transfer submodule 1 16 and a flight submodule 118. These various submodules 
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process information received into the overall dispatch module 100. For example, crew 
information 120 is processed within the schedule submodule 112. In addition, scene 
information 122 is processed within the standby submodule 1 14. 

Patient demographics and patient lab information 124 is processed within the 
5 transfer submodule 116. Flight tracking and other transportation information 126 is 
processed within the flight submodule 118. Once the various submodules within the 
dispatch module 10 have processed their respective information, a set of patient 
demographic information 130 and flight information 135 is made available to the 
remaining modules. For example, some of the patient demographic information 130 is 

10 imported into the clinical module 105. 

In addition, many other pieces of data are placed within the clinical 
module 105. For example, the general assessment 140 of the patient that is taken by the 
emergency medical team is imported into the clinical module for further processing. In 
addition, other incident information 142 such as the type of incident (car accident, 

15 motorcycle accident, etc.) is sent to the clinical module 105. Prior treatment 

information 144 obtained from a physical exam of the patient or other information is 
also sent to the clinical module 105. 

The prior treatment information might be important in determining whether the 
patient had already been treated for similar injuries thereby affecting the clinical 

20 diagnosis. Information collected from the physical exam 146 at the scene is also sent to 
the clinical module 105. In addition, any diagnosis 148 from the attending emergency 
medical team can be sent to the clinical module 105. It should be noted, as discussed 
below, that the medical database system 1 0 may also provide a diagnosis based on the 
physical exam information 146 and other information within the clinical module 105. 

25 This will be explained in more detail below. 

Information relating to the treatment 150 of the patient is also sent to the clinical 
module 105. The medical database system 10 also includes a quality assurance database 
1 52 which allows the emergency medical team to make suggestions or other comments 
that may be useful in additional treatments or incidents. For example, if the emergency 

30 medical team notes that a particular series of exam results has led to a unique diagnosis, 
this information can be input into the clinical module 105. Thus, the next time these 
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same physical exam results are seen in a patient, the new diagnosis can be suggested to 
the emergency medical team. 

Once the clinical module 105 has received its necessary information, data is 
output to the billing module 110. For example, a description of the diagnosis 160, a 
5 treatment description 162 or ICD-9 codes 165 can be sent from the clinical module 105 

to the billing module 110. As is well known, ICD-9 codes are a set of unique codes 
referring to most well known medical procedures. These codes are used throughout the 
insurance industry to obtain payment for various medical procedures. In addition to the 
data from the clinical module 105, patient data 168 can be obtained from the patient 

10 demographic information 130. The flight information 135 can also be retrieved into the 
billing module 110. This information is then used within the billing module 110 to 
generate reports and bills 170. As can be expected, these reports and bills are sent to the 
various insurance companies and insurance providers. Thus, the medical database 
system 10 is an integrated system for providing many services within the medical 

1 5 industry. 

DESCRIPTION OF SOFTWARE MODULES 

1) The Dispatch Module 

Referring now to Figure 4, a flow diagram illustrating the initialized dispatch 
20 module process 65 (Figure 2) is described. The process 65 begins at a start state 200 
and then moves to state 202 wherein the scheduling submodule is initialized. The 
scheduling submodule receives information 120 related to the emergency medical team 
crew, type of vehicle and other scheduling related information. The process 65 then 
moves to state 204 wherein any information relating to the transportation base is 
25 updated. . The base includes the permanent physical location of the ambulance 26 or 
helicopter 24. Base information may also include the particular helicopter or ambulance 
chosen and the emergency medical team that will be in charge of the particular patient 
encounter, as well as base status (available, closed or reserved), and base-specific 
weather (visibility, precipitation, temperature, chill factor and cloud ceiling). 
30 The process 65 then moves to state 206 wherein any shift information from the 

crew is imported into the scheduling submodule. A flight record is then begun at a state 
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208 and the process 65 moves to a decision state 210 to determine whether the crew is 
in a standby mode (e.g. waiting for a call). If a determination is made at the decision 
state 210 that the crew has been placed in a standby mode, the process 65 moves to a 
decision state 212 to determine whether a dispatch order has been given. If a dispatch 
5 order is not given, then a new record can be initiated by the dispatcher at a state 214 and 

the process returns to the decision state 210. 

If a determination is made that the crew has received a call and is no longer in a 
standby mode at the decision state 210, or has been dispatched at the decision state 212, 
the process 65 moves to a decision state 216 (Figure 4b) to determine whether the 

10 ambulance or helicopter will be transporting a patient from an incident scene to a 

hospital facility. If the type of transport is not from a scene to a hospital facility, the 
process 65 moves to a decision state 218 to determine whether an interfacility transfer, 
such as between hospitals, is required. If an interfacility transfer is required, the process 
65 moves to state 220 and updates any interfacility information in the medical database 

1 5 system. 

The process 65 then moves to state 224 to determine whether the interfacility 
transfer is in compliance with the Consolidated Budget Reconciliation Act (COBRA) or 
the Omnibus Budget Reconciliation Act (OBRA). The process 65 then moves to a 
decision state 226 to determine whether the interfacility transfer is within the COBRA 

20 compliance guidelines. If the interfacility transfer is not within COBRA compliance 

guidelines, then the process requests updated information at a state 228 and returns to 
state 220 to update the interfacility information. 

If a determination is made at the decision state 226 that the interfacility transfer 
is within COBRA compliance, the process 65 moves to state 230 and begins to track the 

25 flight coordinates. In addition, if a determination was made at the decision state 216 

that the type of transfer was from an accident scene, then the process 65 jumps to state 
230 and begins flight tracking. Similarly, if a determination was made at the decision 
state 218 that the transfer was not an interfacility transfer, the process 65 jumps to state 
230 and begins flight tracking. Some flights, such as for promotions, are neither from a 

30 scene or for an interfacility transfer. 
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Once flight tracking has begun at the state 230, the process 65 moves to a 
decision state 235 to determine whether any in-flight diversions have taken place. An 
in-flight diversion may arise because for example, a more acute emergency develops 
while the crew is en route. If a diversion has taken place, the reasons for the diversions 
5 are requested at a state 237. However, if no diversions take place during the flight, the 
process 65 verifies the flight information at a state 239 (Figure 4c) and moves to a state 
245 to verify the landing zone specifications for the helicopter. For instance, the 
specifications may relate to noise regulations, local high voltage lines or the like. The 
process 65 then moves to a decision state 248 to determine whether the mandatory fields 

1 0 in the database have been completed. The mandatory fields are data points that must be 
collected before a file can be closed. For example, the patient's name, address, and 
phone number might be chosen by the crew as mandatory fields. The file cannot be 
closed until these flagged fields contain data. If the mandatory fields in the database are 
not completed, the process 65 returns to state 239 to verify the flight information. 

15 If the mandatory fields are completed in the system, the process moves to a 

decision state 250 to determine whether any sentinel events have occurred. A sentinel 
event is a major happening at the accident site which might require notification to the 
hospital. For example, an sentinel event might be arrival at an incorrect landing zone, 
arrival without a crew member, an incorrect patient description, defective equipment or 

20 a lack of the required medications. If a sentinel event has occurred at the decision state 
250, the process 65 moves to a state 252 and prepares an administrative notification to 
the party that is to be notified of the sentinel event. The process 65 then moves to a 
decision state 256 wherein an inquiry is made to the emergency medical team whether 
any interface improvements, such as additional data fields, reordering data entry screens 

25 or field clarifications could be made into the software. Similarly, if no sentinel events 
occurred at the decision state 250, the process 65 moves to the decision state 256 to 
inquire about interface improvements. This request is a chance for the emergency 
medical team to request improvements for the medical database system. 

If an interface improvement is made at the decision state 256, then a 

30 development module is opened at a state 258 and information is requested about what 
type of interface improvements could be made into the medical database system. The 
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process 65 then moves to a state 260 to generate reports including flight records and 
transfer records. The process 65 then terminates at an end state 262. 

2) The Clinical Module 

5 Referring to Figure 5, the initialize clinical module process 70 of Figure 2 is more 

specifically described. The process 70 begins at a start state 300 and moves to state 302 
wherein the patient demographic information from the dispatch module is imported. The 
process 70 then moves to a state 304 wherein any information related to the incident is 
collected. The incident information may be, for example, the type of accident, location of 

1 0 accident, number of injured parties, etc. The process 70 then moves to a state 306 wherein 
the patient demographics are updated with the new information. 

A determination is then made at a decision state 308 whether any pretreatment of 
the injured parties took place prior to arrival of the emergency medical team. If 
pretreatment did occur, the pretreatment information is collected at a state 3 1 0 and input 

15 into the system 10. However, if no pretreatment occurred, the process 70 moves to state 
312 wherein the patient Glasgow, CRAMS, and Champion trauma scores are determined. 
Once these patient scores have been calculated, the process 70 moves to a decision state 
314 wherein a determination is made whether the scores are internally consistent with one 
another. This internal consistency check is an important feature of the system because it 

20 offers a way to use the collected data to prevent incorrect treatments. If the data items are 
not internally consistent an error handling routine is begun at a state 320 and the process 
returns to the state 312. If the scores are internally consistent, the patient's vital signs are 
received at a state 322. 

The process 70 then moves to a decision state 324 (Figure 5b) to determine 

25 whether the patient's vital signs are consistent with the scores calculated at state 312. If 
the scores are not consistent, the process 70 returns to the inconsistency handling routine 
320. This might be the case if the patient was not scored correctly or if the vital signs 
were input incorrectly into the system 10. If the scores are consistent, the process 70 
moves to a state 326 wherein the fluid balance, including intravenous fluid administration, 

30 blood loss, and urine output of the patient is tracked. 
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A physical exam process 330 is then run on the patient, and will be explained in 
more detail below in reference to Figure 6. Once the physical exam has been run at the 
process 330, a determination is made at a decision state 334 whether the results of the 
physical exam are consistent with the scores from the state 3 1 2 and vital signs from state 
5 322. If a determination is made that the results of the physical exam are not consistent, the 

process 70 returns to the inconsistency handling routine 320. If a determination is made 
that the results of the physical exam at the process 330 are consistent with the scores and 
signs from states 312 and 322, the process 70 moves from decision state 334 to a decision 
state 350 to determine whether the physical exam finding is a diagnosis. Types of 

1 0 findings that are a diagnosis might be, for example, abrasions, lacerations, open fractures, 
dislocations, fractures with deformity, loss of consciousness and shock. 

If a determination is made that the physical exam finding is a diagnosis, then the 
process 70 moves to a state 354 wherein the diagnosis is recorded into the medical 
database system. The process 70 then moves to a process 360 wherein the medical 

1 5 database system determines a diagnosis and rank for the patient. The diagnoses are ranked 
in accordance with the severity of the injury and level of compensation. The process 360 
will be explained in more detail in reference to Figure 7 below. Once the diagnosis and 
rank have been determined at the process 360 a process 370 is begun to collect the 
treatment information for the patient. 

20 Once the treatment plan information is collected at the process 370 the inventory 

used during the treatment is tracked at a state 372. The process 70 then moves to a 
decision state 376 to determine whether the inventory used at the state 372 is consistent 
with the treatment determined at the process 370. If the treatment is inconsistent with the 
inventory used, the process 70 moves to a state 378 and allows an amendment to correct 

25 the procedure documentation so that the inventory will be correctly reflected the next time 

the procedure is logged into the medical database system. The process 70 then returns to 
process 370 to collect the treatment plan again. If a determination is made at the decision 
state 376 that the inventory used was consistent with the treatment, the process 70 
terminates at an end state 380. 

30 
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A) The Physical Exam Process 



Figure 6 describes the run physical exam process 330 of Figure 5 in more detail. 
Referring to Figure 61, the process 330 begins at a start state 400 and moves to state 402 
5 wherein the results of a neurological exam on the patient are received by the medical 
database system. A determination is then made at a decision state 404 whether the 
findings from the neurological exam are themselves a diagnosis. For example, a non- 
responsive, flaccid neurological exam indicates a loss of consciousness diagnosis. If the 
findings are a diagnosis, the process 330 moves to a state 406 to record the diagnosis 
10 within the medical database system. If the finding is not a diagnosis, the process 330 
moves to state 408 wherein the results of a skin exam are received by the medical 
database system. 

□ A determination is then made at a decision state 410 whether the results of the 

skin exam are a diagnosis. If the results are determined to be a diagnosis at the decision 

Ul 15 state 410, their diagnosis is recorded at a state 412 into the medical database system. If 

the results of the skin exam are not a diagnosis at the decision state 410, the process 330 

zl moves to state 420 wherein the medical database system receives the results of a head, 

*_ eyes, ears, nose and throat exam. Now referring to Figure 6b, the process 330 then 

S iM< J: 

jj moves to a state 422 to determine whether the results from this exam are a diagnosis. If 

^ 20 the results are a diagnosis, they are recorded at a state 424 and the process moves to a 

O state 426 wherein the results of a neck exam are received. If a finding were not a 

diagnosis at the decision state 422, the process 330 moves directly to the state 426. 

Once the results of a neck exam are received at the state 426, a determination is 
made at the decision state 430 whether the results of the neck exam are a diagnosis. If 
25 the findings are a diagnosis, the process 330 moves to state 432 wherein the diagnosis is 
recorded into the medical database system. If the finding is not a diagnosis, the process 
330 moves to a state 436 wherein the results of a chest exam are received into the 
medical database system. The process 330 then moves to a decision state 440 wherein a 
determination is made whether the results of the chest exam are a diagnosis. If the 
30 results of the chest exam are a diagnosis, the process 330 moves to state 442 and records 
the diagnosis in the medical database system. 
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The process 330 then moves to a state 446 and receives the results from a 
cardiac exam from the patient. A determination is then made at a decision state 448 
whether the results of the cardiac exam are a diagnosis. If the results are a diagnosis, 
the process 330 moves to a state 450 and records the results of the cardiac exam as a 
5 diagnosis in the medical database system. The process 330 then moves to a state 454 
wherein the results of a pulmonary exam are received in the medical database system. 
A determination is then made at a decision state 456 whether the findings from the 
pulmonary exam are a diagnosis. If the findings are a diagnosis, the process 330 moves 
to a state 460 wherein the diagnosis is recorded in the medical database system. 

10 The process 330 then moves to a state 462 wherein the results of an abdominal 

exam on the patient are received by the medical database system. Now referring to 
Figure 6c, the process 330 then moves to a state 466 wherein a determination is made 
whether the findings from the abdominal exam are a diagnosis. If the findings are a 
diagnosis, the process 330 records these findings at a state 470 and moves to a state 472 

1 5 wherein the results of a pulse exam are received into the medical database system. As is 
known, a pulse exam typically includes interval recordings or blood pressure, heart rate, 
respiratory rate and pulse oximetry. 

Once the results of the pulse exam are received at the state 472, a determination 
is made at a state 474 whether the findings from the pulse exam are a diagnosis. If the 

20 findings are a diagnosis, they are recorded at a state 476 and the process thereafter 
moves to a state 480 wherein the results of a back exam are received. If the findings 
from the pulse exam are not a diagnosis, the process 330 moves directly from the 
decision state 474 to the state 480. 

Once the results of the back exam are received at the state 480, the process 330 

25 moves to a decision state 482 wherein a determination is made whether the findings 

from the back exam are a diagnosis. If the findings are a diagnosis, the process 330 
records the diagnosis at a state 484 and moves to a state 486 wherein the results of an 
extremities exam are received by the medical database system. 

If a determination were made that the finding was not a diagnosis at the decision 

30 state 482, the process 330 moves directly to the state 486. One the results of the 
extremities exam are received by the medical database system, the process 330 moves to 
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a state 490 wherein a determination is made whether the findings from the extremities 
exam are a diagnosis. If the findings are a diagnosis, they are recorded in a state 492 
and the process 330 thereafter moves to a decision state 494 to determine whether the 
findings throughout the process 330 are consistent with one another and the trauma 
5 scores. For example, a normal verbal response would not be consistent with a flaccid 

neurological finding. Similarly, a normal respiratory score may not be consistent with a 
tension pheumothorax finding. 

If the findings are inconsistent, the process 330 moves to an inconsistency 
handler 496 to request information from the emergency medical team why the findings 
1 0 are inconsistent with one another. Once the inconsistency handler 496 has determined 

that the findings are now consistent, the process 330 moves to a state 498 wherein any 
amendments are made to the proper physical exam record. The process 330 then moves 

p% to a decision state 500 wherein a determination is made whether all of the mandatory 

fields have been completed for this module. If the mandatory fields have not been 

Ul 15 completed, the process 330 moves to an error handler 502 to request information about 

the empty, mandatory fields. The process 330 then terminates at an end state 504. 

ol 

s B) The Process of Determining a Diagnosis and Rank 

^ 20 Figure 7 describes the process 360 of determining the diagnosis and rank for a 

□ patient (Figure 5) in more detail. The process 360 begins at a start state 550 and then 

moves to a state 552 wherein a list of possible diagnoses is generated based on the results 
of the clinical exam. Thus, the suggested diagnoses are linked to the physical exam 
scores received earlier by the system. The patient historical data, physical exam data and 
25 procedural data are all taken into account when the system calculates possible diagnoses. 

For example, if an unconscious patient with a head injury documented in history 
and the physical exam might be linked to a "acute closed head injury with loss of 
consciousness" diagnosis. However, if a member of the emergency medical team had 
inadvertently chosen in the chart that the patient was verbalizing normally, the system 
30 would request an explanation of the discrepancy. 
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Once the list of possible diagnoses are presented at state 552, the process 360 then 
moves to a decision state 556 to determine whether any diagnoses from the generated list 
are consistent with the results of the clinical exam. If a determination is made that none of 
the diagnoses are consistent with the results from the clinical exam, the process 360 moves 
5 to a state 558 wherein a diagnosis is requested from the emergency medical team. The 
process 360 then moves to a decision state 560 wherein the diagnosis entered by the 
emergency medical team is correlated with the results from the clinical exam. If the 
results do not correlate, the process 360 moves to a state 564 wherein the medical database 
system requests an explanation of the discrepancy between the entered diagnoses and 

10 results of the clinical exam. The explanation and diagnoses are then recorded in the 
medical database system at a state 566. The process 360 then moves to a state 570 
wherein a diagnosis is selected. 

However, if any diagnosis were determined to be consistent at the decision state 
556, or if any input diagnosis correlated with the results of the clinical exam, the process 

15 360 would move immediately to the state 570 wherein one of the diagnoses is selected. 
The process 360 then moves to a state 574 wherein a treatment protocol is suggested based 
on the diagnosis selected at the state 570. For example, an intubation protocol might be 
suggested based on a heart attack diagnosis. The process 360 then moves to a state 576 
wherein the ICD-9 code is retrieved for the suggested treatment protocol from state 574. 

20 A determination is then made at a state 578 whether the ICD-9 code is complete, including 
all subcode numbers. If the code is incomplete, the process 360 displays a list of potential 
subcodes at a state 580 and the process moves to a state 582 wherein the proper code is 
selected from the list. The process 360 then returns to state 576 to retrieve the proper 
ICD-9 code. If a determination was made at the decision state 578 that the complete 

25 ICD-9 code was retrieved, the process terminates at an end state 590. 

3) The Administration Module 

Referring now to Figure 8, the initialize administration module process 75 
(Figure 2) is described in more detail. The process 75 begins at a start state 700 and 
30 then moves to state 702 wherein the demographic information from the other software 
modules within the medical database system are imported into the administration 
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module. The process then moves to a decision state 704 wherein a determination is 
made as to whether the demographic information is consistent with the information 
contained in the other modules. For example, a patient's name might be recorded 
differently in the dispatch and clinical modules. Similarly, the social security number or 
5 insurance information might be inconsistent between modules. If the information is 

inconsistent, the process 75 moves to a state 706 wherein the information is amended to 
conform with the data within the other modules. The process then returns to the state 
702 to re-import the demographic information. 

If a determination were made at the decision state 704 that the demographic 

10 information was consistent between each module, the process 75 moves to a state 708 

wherein the treatment codes from the patient encounter are collected into the medical 
database system. The process then moves to a state 710 wherein the inventory codes, 
such as ICD-9, are collected into the administration module of the medical database 
system. The process 75 then moves to a state 712 wherein a calculation is performed to 

1 5 determine the amount of inventory needed to restock the base station so that an ample 

quantity of medical supplies will also be available to the emergency medical team. The 
process 75 then moves to a decision state 720 to determine whether the treatment codes, 
inventory codes and base inventory calculations are consistent with one another. For 
instance, was an intubation tube used for a warranted intubation and not for a 

20 pericaridocentesis procedure. Further, this decision checks that the amount and coding 

of the used supplies are correct and that, for example, an intubation tube is recorded and 
not a chest tube. If a determination is made that the data are not consistent, the process 
75 makes amendments at a state 721 and returns to the state 708. If a determination is 
made that the data are consistent, the process 75 moves to a state 722 wherein the 

25 quality assurance incidents are collected. The quality assurance incidents can include 

procedure complications, equipment difficulties, crew interaction problems and 
organizational mismanagement. 

The process 75 then moves to a state 724 wherein any sentinel events that 
occurred during the patient encounter are collected into the administration module. As 

30 discussed previously, a sentinel event is one which might require notification to a third 
party. Such an event might be repeated failed procedures by a crew member, prolonged 
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scene times, incorrect administration of medicine, performance of non-indicated 
procedures and unwarranted deviation from treatment protocols. The process 75 then 
moves to a state 726 wherein reports are generated from the administration module to 
the proper target audience. The target audiences may include administrators, collectors, 
5 insurers, supervisors, medical directors and governmental organizations. The process 
75 then terminates at an end state 730. 

A) The Collecting a Treatment Plan Process 

Referring now to Figure 9a, the process of collecting a treatment plan 370 

10 (Figure 5) is described in more detail. The process 370 begins at a start state 800 and 
moves to a state 802 wherein the patient's Basic Life Support (BLS) treatment 
information is collected by the medical database system. The BLS treatment 
information might include vital signs, results of an initial survey, fluid balances and 
immobilization procedures. 

15 The process 370 then moves to a state 804 wherein the patient status is 

monitored by the emergency medical team. The status is then updated into the medical 
database system as changes occur in the patient's condition. The process 370 then 
moves to a decision state 810 wherein a determination is made whether any advanced 
procedures were administered to the patient. If advanced procedures were administered 

20 to the patient, the process 370 moves to a state 812 wherein the indications for the 
patient are recorded within the medical database system. A determination is then made 
at a state 814 whether the recorded indications are consistent with the results of the 
clinical exams and the vital signs. This feature of the system provides an efficient 
correcting mechanism and ensures that accurate information is entered into the system. 

25 If a determination is made at the decision state 814 that the indications are 

consistent, the process 370 moves to a state 820 wherein the procedures used on the 
patient are recorded. However, if a determination is made at the decision state 814 that 
the findings and vital signs are not consistent with the recorded indications, the process 
370 moves to a state 822 wherein the indications, findings or vital signs, can be 

30 amended within the medical database system. The process 370 then returns to the state 
820. 
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Once the procedures are recorded at the state 820, the process 370 moves to a 
state 822 wherein any procedure notes can be entered into the medical database system. 
The process then moves to a decision state 830 (Figure 9b) wherein a determination is 
made whether all of the mandatory fields have been captured in the treatment record. If 
5 some of the mandatory fields have not been captured, the process 370 returns to state 
820 wherein the attending emergency medical personnel are prompted to enter data into 
the mandatory fields. However, if a determination is made that the mandatory fields 
have been captured, the process moves to a state 834 wherein the inventory used in the 
advanced procedures are collected. Because the inventory used is collected at the 

1 0 incident scene, it is less likely that some inventory will be forgotten to be entered. In 
addition, validity checking can be done to ensure that the inventory used correlates with 
the treatments that were performed. 

The process then moves to a state 836 wherein the patient status following the 
procedure is monitored and any indications are input into the medical database system. 

15 The process 370 then moves to a decision state 840 wherein a determination is made 

whether any complications exist such as esophageal intubation, broken teeth or 
excessive bleeding that should be recorded into the medical database system. If such 
complications do exist, the process moves to a state 842 and records the complications 
in the medical database system log. The process 370 then moves to a decision state 846 

20 wherein a determination is made whether any sentinel events occurred during the 
treatment. 

If no sentinel events did occur, the process moves to a state 848 wherein the 
party responsible for the patient, such as the hospital, is notified. However, if any 
sentinel events did occur, the process 846 moves to a decision state 849 wherein the 
25 record for that patient is flagged to indicate that sentinel events occurred during the 

treatment period. The process then returns to the state 848 and terminates at an end 
state 850. 

4) The Billing System 

Referring now to Figure 10, the initialize billing module process 80 (Figure 2) is 
30 described in more detail. The process 80 begins at a start state 900 and then moves to a 

state 902 wherein a unique invoice number is generated for the bill. The process 80 
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then moves to a state 904 wherein a particular person (e.g.; a collector) is assigned to 
the invoice number generated at the state 902. The collector is responsible for tracking 
the progress of the invoice to ensure that it is eventually paid. Once a collector has been 
assigned at the state 904, the process 80 moves to a state 906 wherein the 
5 payor/demographic data is collected to identify the insurance company, HMO or 
individual patient responsible for paying the outstanding bill. The process 80 then 
moves to a state 908 wherein the clinical diagnosis data from the patient encounter is 
collected into the billing module. This information is used to describe the clinical 
encounter on the bill. 

10 The process 80 then moves to a state 910 wherein the clinical procedure data 

from the clinical encounter is collected into the billing module. The clinical procedure 
data includes all of the procedures performed by the emergency medical team at the 
f ^ incident site. The specific treatments given to the patient at the incident site are then 

'bar? 

2f collected into the billing module at a state 912. The process 80 then moves to a state 

U1 15 920 wherein the inventory data corresponding to the number of syringes, drugs and 
qi other paraphernalia used by the emergency medical team are collected. 

Once all of the data from the states 906 to 920 are collected, a determination is 
* made at a decision state 924 whether there is any new data to be entered into the system. 

d% New data could relate to updated insurance policy information, patient addresses or any 

^ 20 other data that needs to be amended or added. If a determination is made that new data 

□ does exist, the process 80 moves to a state 926 wherein the appropriate data is amended 

so that it can be extracted. 

If a determination is made at the decision state 924 that there is no new data to 
enter, the process 80 moves to a decision state 926 to determine whether the extracted 
25 data is consistent with the requirements of the payor. For example, the payor may 

require that the inventory data include the name of the address of the vendor responsible 
for selling the medical equipment inventory item . If this information was not collected 
with the inventory data, it would be inconsistent with the payor requirements. If a 
determination is made that the data is inconsistent with the payor requirements, the 
30 process 80 returns to state 926 so that the data can be amended. 
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However, if the data is consistent with the payor requirements at the decision 
state 926, the process 80 moves to a decision state 930 to determine whether the data is 
consistent with legislative and regulatory requirements. The legislative requirements 
may relate, for example, to the specific dosages and types of drugs given to the patient 
5 during the encounter. Other legislative requirements may relate to the personnel 
configurations required for patient transport, procedure practices or types of necessary 
documentation. For example, it may be required that at least one doctor, one nurse and 
one emergency medical technician be sent to every call. If the data is inconsistent with 
legal requirements, the process 80 moves to a decision state 934 to determine whether 
10 the data relates to a sentinel event that occurred during the patient encounter. If a 
sentinel event did not occur, the process 80 returns to the state 926 so that the data can 
be amended to indicate the nature of the inconsistency. However, if the data did relate 
to a sentinel event, the process 80 moves to a state 936 to flag the data as a sentinel 
event (as defined above). This flag can then alert the payor that a sentinel event 
15 occurred which may require a special billing procedure. 

If a determination is made that the data was consistent with legislative 
requirements at the decision state 930, the process 80 moves to a state 934 wherein the 
payment codes corresponding to all of the data is determined. The payment codes can 
be the industry standard ICD-9 codes or any other code required by the payor. 
20 The process 80 then moves to a decision state 940 to determine whether the 

payment codes are consistent with the payor's contract. Normally, each payor's 
requirements are programmed into the billing module. These requirements usually 
relate to the format and content of the invoice. If a determination is made that the 
payment codes and data are inconsistent with the contract, the process moves to the 
25 decision state 934 to determine whether a sentinel event had occurred. As discussed 

above, sentinel events can be events that happen during the patient encounter that are 
worthy of special attention. The occurrence of a sentinel event might be one reason the 
payment codes are inconsistent with the contract terms at the decision state 940. For 
example, a misdiagnosis leading to an improper treatment would be one type of sentinel 
30 event that could lead to a treatment code not corresponding properly with a diagnosis 

code in the contract. 
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If the payment codes and data were consistent with a contract, the process 80 
generates a bill at a state 944 and moves to a state 946 to determine the proper payment 
plan for this payer. For example, the payment plan might be a net payment due in 60 
days with a 2% discount for payments made within 30 days. A determination is then 
5 made at a decision state 948 whether the payment plan chosen is consistent with the 

requirements from the patient's health care providing entity or institution. If a 
determination is made that the payment plan is not consistent, the process 80 moves to a 
state 950 wherein the payment plan is reviewed. The process 80 then returns to state 
946 to determine a new payment plan. 
10 If a determination is made at the decision state 948 that the payment plan is 

consistent with the contract, the plan is assigned at a state 960 and an electronic bill is 
submitted via, for example, an electronic communication or computer diskette at a state 
962. A printed copy of the claims can then be submitted to the appropriate insurance 
company or agency at a state 963. The process then moves to a decision state 964 to 
1 5 determine if any payment has been received. If a determination is made at the decision 

state 964 that payment has been received for the bill submitted at the state 962, a report 
is generated at a state 968 and the process terminates at an end state 970. 

However, if a determination is made that the payment has not been received at 
the decision state 964, the process 80 makes a decision whether to retire the insurance 
20 claim of a specific amount of money at a decision state 974. As is known in the art, to 
retire a claim is to flag it as uncollectable so that a collection agency is thereafter 
involved. If a determination is made at the decision state 974 that the claim is not to be 
retired, the process 80 moves to a state 976 wherein a follow-up on the bill is performed 
to gather more information concerning the payment. For example the number of days 
25 can be calculated between the invoice date and the current date to determine if the 
payment is late. The process 80 then gathers additional information from the payer at a 
state 978 and generates a billing report listing the accounts receivable at a state 980. 
The process then returns to the state 924 to determine whether all data had been 
extracted from the other modules. 
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If a determination is made at the decision state 974 to retire the claim, a 
collection agency is notified at a state 984 and the process thereafter moves to the state 
968 to generate reports concerning the outstanding bill. 

While the invention has been described in connection with specific embodiments 
5 thereof, it will be understood that it is capable of further modification, and this application 

is intended to cover any variations, uses, or adaptations of the invention following, in 
general, the principles of the invention and including such departures from the present 
invention as would be understood to those in the art as equivalent and the scope and 
context of the present invention is to be interpreted as including such equivalents and 
1 0 construed in accordance with the claims appended hereto. 
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